Currently data of Ipv4 is transported largely over telecommunications facilities or channels to support IP protocols and to provide IP-related applications. One of the best channels is SDH and related WDM(wavelength Division Multiplex) optical transport network are considered to be the foundation for the physical layer of the broadband IP and B-ISDN. SDH/SONET had been deployed all over the world in recent ten years.
ITU-T G.707 describes the advantages offered by SDH and multiplexing method, and specifies a set of SDH bit rates, the general principles and frame structure of the network node interface(NNI), the overall frame size of 9 rows by N*270 columns, the section overhead(SOH) together with its byte allocation, arrangements for international interconnection of synchronous transport modules(STMs), the formats for multiplexing and mapping elements into the STM-N at the NNI.
The North America equivalent of SDH is SONET. SONET is the U.S.(ANSI) standard for synchronous data transmission on optical media. People ensures standards so that digital networks can interconnnect internationally and that existing conventional transmission systems can take advantage of optical media through tributary attachments. SONET defines a base rate of 51.84 Mbps and a set of multiples of the base rate known as Optical Carrier Levels. The SONET is an octet-synchronous multiplex scheme that defines a family of standard rates and formats. Despite the name, it is not limited to optical links. Electrical specifications have been defined for single-mode fiber, multi-mode fiber, and CATV 75 ohm coaxial cable. The transmission rates are integral multiples of 51.840 Mbps, which may be used to carry T3/E3 bit-synchronous signals. It is also strong recommended to use G.703 E1/E3/E4/T1/E2/T4 interfaces as physical layer of IP-over-SDH/SONET. It is convenient user access way via LAN.
Both SDH and SONET provide standard for a number of line rates up to the maximum line rate of 9.953 gigabits per second(Gbps). Actual line rates approaching 20 gigabits per second are possible.
How to fully make use of these existing huge broadband resources effectively to provide Internet data communication services? How to combine IP-based network with SDH/SONET to establish the lower cost and high-speed based protocol model? RFC 2225(1998) defines an initial application of classical IP and ARP in an asynchronous Transfer Mode(ATM) network environment configured as a Logical IP Subnetwork(LIS), and considers only the application of ATM as a direct replacement for the “wires” and local LAN segments connecting IP end-stations(“Member”) and routers operating in the “classical” LAN-based paradigm. RFC 1619(1994) describes the use of PPP over SONET and SDH circuits. PPP(RFC 1548, 1993) was designed as a standard method of communicating over point-to-point links. Initial deployment has been over short local lines, leased lines, and plain-old-telephone-service(POTS) using modems. As new packet services and higher speed lines are introduced, RFC 1717(1994) proposes a method for splitting, recombining and sequencing datagram across multiple logical data links.
The rapid growth of Internet/Intranet has led to a need to establish a framework of telecom Intranet/Intranet (e.g. QoS, priority, account management), meanwhile, it is necessary and also very important to think about the requirement for compatibility with the current Internet protocol(Ipv4) at other Internet/Intranet areas and next generation Internet protocol(Ipv6).
Currently, the method for adapting IP to SDH/SONET is PPP (including LCP and NCP) over HDLC of RFC 2615 protocol, which includes RFC 1661, RFC 1662, RFC 1570, RFC 1547, RFC 1340. PPP can encapsulate more than 30 network protocols, including Ipv4. However, PPP was originally proposed for inter-protocol adaptation for Modem dial-up(firewall), the algorithm for PPP is complicated.
When applying PPP over SONET or SDH, there exist the following defects:    (1) no standard supports for lower level virtual container applications, which results in IP over SDH/SONET can not be applied to Internet edge access;    (2) for 2.5 Gbps rate or up, the overhead of hardware forwarding engine is too heavy, especially for IP over WDM using simplified SDH/SONET frame, since in RFC 1619, LCP and Magic Number are recommended, both of which are very complicated;    (3) in case the RFC 1619 is used, the default value of the retransmit timer is 3 second in PPP, which is too slow for high speed link. For specific engineering applications, it is required to support all the rate range from 2M bit to 10000M bit/sec(change about 4032 times), therefore the value of the retransmit timer should be determined based on the round-trip delay along the line. However, it is not defined in RFC 1619, causing uncertainty when interconnecting equipment from different vendors;    (4) The padding field of PPP is almost not used in the case of IP over SDH/SONET, but it still kept now in RFC 2615. In addition, this padding field requires a function at the receiver side to distinguish between information field and padding field which would have been defined in RFC standard, and at the same time which in turn increases the processing overhead;    (5) LCP contains 10 configuration packets, 16 events and 12 actions, and more than 130 protocol states, which is difficult and costly to implement for optical packet exchange. For illustrating the above, Table 1 show the list of Events and Actions using the conventional PPP over SONET/SDH standard on finite-state machine of LCP.    (6) Due to the introduction of PPP, the minimum packet size linked between two routers is reduced from (about) 40 bytes for Ipv4 to (about) 10 bytes for PPP. The ratio of MPS/mPS is increased from 1600/40(=40), to 1600/10(=160), i.e. the span of a packet (prescribed as the ratio of MPS/mPS) is increased by 4 times. Consequently, it becomes more difficult for the router to perform synchronous processing and forwarding of cell based or packet based for locating small packets(e.g. 64 bytes) based on cell or equal size, which results in significant degradation of networking performance, such as packet loss rate, time delay, trembling of time delay, etc.
TABLE 1The list of Events and ActionsEventsActionsUp= lower layer is Uptlu =  This-Layer-UpDown= lower layer is Downtld =  This-Layer-DownOpen= administrative Opentls =  This-Layer-StartedClose= administrative Closetlf =  This-Layer-FinishedTO+= Timeout with counter>0irc =  Initialize-Restart-CountTO− = Timeout with counter expiredzrc =  Zero-Restart-CountRCR+= Receive-Configure-Request (Good)scr =  Send-Configure-RequestRCR−= Receive-Configure-Request (Bad)RCA= Receive-Configure-Acksca = Send-Configure-AckRCN= Receive-Configure-Nak/Rejscn =  Send-Configure-Nak/RejRTR= Receive-Terminate-Requeststr = Send-Terminate-RequestRTA= Receive-Terminate-Acksta =  Send-Terminate-AckRUC= Receive-Unknown-Codescj =  Send-Code-RejectRXJ+= Receive-Code-Reject (permitted) or Receive-Protocol-RejectRXJ−= Receive-Code-Reject (catastrophic) or Receive-Protocol-RejectRXR= Receive-Echo-Requestser =  Send-Echo-Reply or Receive-Echo-Reply or Receive-Discard-Request
For exemplary purpose, FIG. 1 illustrates the line card structure in a conventional PPP over SDH router. As shown in FIG. 1, as components of a router 1, there are a plurality of line cards 2-1, . . . 2-N, each of which is connected to a switch fabric unit 3. For each of the line cards, the HDLC-like data frames from O/E module 5 are received by an OC-192c/48c/12c/3c or STM-64c/16c/4c/1 transceiver 6 and transmitted to a POS(PPP over SDH/SONET) mapper/demapper 7 (which is also called Framer/De-framer). In the POS Framer/Deframer 7, the PPP frames encapsulated in the HDLC frames are extracted out and transmitted to a packet forwarding engine 8, which operates in cooperation with a routing engine 4, for PPP processing. The routing engine 4 is a software executed by a global embedded CPU in the router. The forwarding engine 8 forwards the data packets to the switch fabric unit 3 by using a mechanism of combining IP address subset of routing table or forwarding information base to line card identifier, so as to send the data packets to the destination thereof. PPP functions are implemented in the forwarding engine and the routing engine, which is for network layer (IP) processing, in each of the line cards inside the router.
FIG. 2 illustrates one implementation of the PPP processing in the network layer in a conventional line card. Here the data rate is supposed to be 2.5 G bit/s, for example. In FIG. 2, the filter function of PPP(LCP, NCP) can be implemented in hardware, such as a FPGA(field programmable gate array) with about more than 50,000 gates, as the forwarding engine, while the other LCP functions are implemented in form of software, as the routing engine. Or alternatively, all the PPP, LCP, NCP functions can be implemented in hardware as the forwarding engine, which can be a FPGA with about more than 500,000 gates. In addition, a PPP software can have up to 10,000 lines of C codes, and cost up to tens of thousand USD.
In connection with the complexity of Mapper/Demapper chips and Network processing engine chips in the line cards (see FIG. 1), having investigated Mapper/Demapper chips solution of several vendors, the inventor found already:
When configured for POS mode, the transmit HDLC processor of Mapper/Demapper provides the insertion of HDLC frame into the SPE, It will perform packet framing, inter-frame fill and transmit FIFO error recovery. In addition, it optionally performs scrambling (X43+1), either pre or post HDLC processor, perform transparency processing specified in RFC 1662 and will optionally generate a 16/32 bit FCS.
The receive HDLC processor provides for the extraction of HDLC frame, transparency removal, de-scrambling (if enable), FCS error checking, and optional delete the HDLC address and control fields. The function of LCP and NCP are not covered in Mapper/Demapper chips.
POS PHY interfaces have been defined as 8 bit parallel 25 Mbps for OC-3/STM-1, 16 bit parallel 50 Mbps for OC-12/STM-4, and 32 bit parallel 100 Mbps or 64 bit parallel for OC-48/STM-16.
The handling of different LCP packets of PPP, the processing of link establishment, Authentication, Network-Layer Protocol phase and Link Termination, the forming of State Transition Table, will be implemented either in network processor engine or in global routing engine transferred from network processor. Many vendors, i.e. Agere, Broadcom, Conexant, C-port, IBM, Intel, Lucent, Maker, MMC network, Motorola, Sitera, softcom, TI and Vitesse (some European, Japanese and Chinese companies are also included) are developing network processor engine of either packet-based or cell-based or both packet and cell based. For example, the network processor of some company will be released or is available now, it has more than 800 pins of BGA package, and associated a set of software development and testing tools are also needed for building of line cards. This engine has multi-protocol processor and are complicated very much, although many necessary functions of this engine are involved in IP-based forwarding, such as input stream scheduler, receive stream parse, look-up and update, receive editor, input queue manager, output queue manager, transmit editor, output stream scheduler, interface to SSRAM, SDRAM and SNMP network management and so on. The programming of microcode based or lower-layer classification based language is usually used up to now. The next objective is to build a pure ASIC so as to implement IP-forwarding. In these two case above, it means the use of LCP and NCP protocol functions means that this engine is added a′ n extra burden, since the wired-speed forwarding of IP-based is still basic requirement. It can be believed that there is no problem to build all functions including these PPP mechanism (i.e. Nexabit has implemented PPP over OC-192 between Chicago and Cleveland), even if the situation is complicated further ten times than ever before. But main point to reduce cost, raise efficiency can not be obtained from the conventional design.
It can be seen that the conventional PPP over SDH/SONET solution is complex, difficult and expensive to implement, slow, and not suitable for high speed data transmission, especially for gigabit rate applications.